В предыдущих статьях о ESB-решениях эксперты KT.Team рассказали, для чего нужны такие решения (см. статью «Инструмент, который поможет сохранить молодость бизнеса→»), какие из них популярны на российском рынке (см. статью «Сравнение ESB-решений, популярных на российском рынке. Часть 2: особенности систем→») и какие этапы предстоит пройти при внедрении ESB (см. статью «От спагетти до гибкой архитектуры за 5 шагов: этапы внедрения ESB-слоя→». Допустим, вы уже определились, что внедрение сервисной шины станет лучшим решением ваших проблем. Следующий шаг — понять, каких усилий и ресурсов оно потребует.
Эта статья предназначена для руководителей, которые отвечают за внедрение ESB, контролируя бюджет, выбор технологического стека и сам процесс внедрения. Она поможет учесть основные затраты, обязательные для бюджетирования при самостоятельном внедрении, и обратить внимание на ключевые аспекты ведения переговоров с подрядчиком, если вам понадобится его помощь.
Мы поможем разобраться с часто возникающими вопросами.
- Из каких шагов состоит внедрение ESB и сколько времени оно занимает?
- Из чего складывается стоимость внедрения ESB-решений и владения ими?
- Какие специалисты нужны для внедрения и поддержки ESB? Что обычно делают своими силами, а для чего чаще привлекают подрядчиков?
- Каковы наиболее распространённые ошибки при внедрении ESB и как их избежать?
Причины внедрения ESB
Как правило, компании приходят к внедрению middleware-слоя, поработав по одному из двух типичных сценариев.
Сценарий первый: IT-архитектура компании долгие годы разрасталась вокруг монолитной системы формата «всё в одном». В первые годы жизни компании она закрывала все потребности бизнеса в части IT-обеспечения, затем команда дописывала и дорабатывала её… пока в конце концов отказ от любой из частей этой системы не стал слишком сложным и дорогим. Но при этом IT-департамент (и другие подразделения компании) прекрасно понимает, что на рынке есть гораздо более гибкие, удобные и лёгкие в поддержке системы для конкретных бизнес-процессов компании. И сейчас перед вами стоит задача заменить тяжеловесный монолит на отдельные сервисы и микросервисы.
Сценарий второй: IT-архитектура уже состоит как минимум из десятка систем, объединённых интеграциями вида «точка – точка». Добавление в такой контур новых систем — дорого и долго, а поддержание работоспособности существующих интеграций — высокозатратно. При этом данные из старых систем выгружаются в сложных и неудобных форматах. Слой middleware вам нужен для того, чтобы распутать интеграции и сделать архитектуру более гибкой и лёгкой в поддержке и обновлении.
При этом в IT-департамент постоянно обращаются другие подразделения с регулярно повторяющимися проблемами и задачами:
- маркетинг не может свободно развивать каналы привлечения пользователей, т. к. трафик от удачных рекламных кампаний создаёт риск падения системы;
- коммерческий отдел не может внедрить перспективный продукт или осуществить интеграцию, т. к. возникнет поток сообщений между приложениями, с которым ваша система не сможет справиться;
- группа компаний приобретает новые предприятия, но не может извлечь всей выгоды из интеграции их данных, хранящихся в разнородных IT-системах (например, агрегировать данные в режиме реального времени и создавать уникальные автоматизированные продукты или аналитические инструменты).
Внедрение ESB — логичный шаг. Но не обладая опытом реализации аналогичных проектов, довольно сложно предсказать, сколько времени займёт этот процесс, сколько он будет стоить на этапе внедрения и владения и каков будет его экономический эффект.
Обо всём — по порядку. Для начала разберёмся с последовательностью действий при внедрении ESB-слоя.
Предпроектное обследование
На этом этапе команда экспертов изучает существующие потоки данных, выстраивает схему будущей архитектуры, производит калькуляцию стоимости внедрения.
Не все IT-интеграторы, которые специализируются на внедрении ESB-систем, готовы предоставлять аналитические услуги отдельно от реализации проектов. Поэтому, чтобы вычленить данный этап из общей стоимости и длительности, рекомендуем собрать и рассмотреть несколько коммерческих предложений.
Что касается практики KT.Team — в нашей компании предпроектная аналитика является отдельной услугой. Как правило, аналитический этап занимает от двух до четырёх недель (в зависимости от масштабов существующей IT-архитектуры, количества и сложности потоков данных) и обходится приблизительно в 1,4 млн руб.
Этап выглядит необязательным, поскольку IT-директор, как правило, хорошо знает IT-контур своей компании. Однако опыт работы KT.Team показал: если пренебречь предпроектным исследованием, процесс внедрения шины замедлится, а стоимость внедрения вырастет.
Так, на проектах, сопоставимых по масштабам, внедрение middleware без предварительного аналитического этапа занимало 1200–1500 часов разработки, правок и доработок, а с предпроектным исследованием — 600 часов.
Этапы внедрения ESB
Мы выделяем пять этапов внедрения ESB в IT-архитектуру предприятия.
Подробнее об этих этапах и их длительности мы рассказываем в статье «От „спагетти“ до гибкой архитектуры за пять шагов: этапы внедрения ESB-слоя», здесь же опишем их вкратце.
Первый этап — выбор места хранения вашего ESB-слоя. Мы предлагаем приступить к этому этапу до выбора технологического стека, т. к. существующие правила и юридические требования могут ограничить вас в выборе основной системы и дополнительных компонентов. Так, например, make подойдёт, только если вы согласны работать через облако. А WSO2 может быть установлена и на выделенных серверах компании.
Второй этап — выбор среды разработки интеграции. Пропускная способность, возможности масштабирования, совместимость с системами логирования и мониторинга, финансовая модель и пр. — учитываются десятки ключевых параметров. В практике KT.Team данный этап включён в предпроектную аналитику: мы предоставляем развёрнутую информацию по трём системам, что позволяет принять более взвешенное решение.
Третий этап — выбор стека компонентов ESB. Здесь вам предстоит выбрать (самостоятельно или с привлечением интегратора): хранилище сообщений (например, брокер сообщений или база данных); системы логирования и мониторинга; хостинг для развёртывания остальных компонентов — собственный или облачный (IaaS-провайдер).
Существуют специализированные SaaS-решения для построения ESB, которые предоставляют хостинг и стек готовых компонентов. Большинство таких SaaS — зарубежные.
Четвёртый этап — развёртывание и настройка компонентов ESB. Как правило, он длится около полутора месяцев до запуска MVP. Завершив развёртывание и конфигурирование компонентов, IT-команда начинает формировать первые потоки данных между приложениями. На этом этапе шина сосуществует с привычной архитектурой и интеграциями. Как правило, команда начинает с самого сложного потока и затем создаёт остальные на его основе.
Продолжительность и, соответственно, стоимость работ могут сильно варьироваться, но — по нашему опыту — в среднем проект внедрения ESB до уровня MVP обходится в 1,5–3 млн руб.
Пятый этап — документирование реализованной ESB. Все действия и правила создания интеграций фиксируются и описываются командой разработки. Правильно составленная документация позволит инженерам, незнакомым с вашей ESB, настраивать новые интеграции в имеющейся у вас архитектуре согласно принятым подходам. Процесс документирования занимает около 40 часов.
Стоимость внедрения и владения ESB
При внедрении и эксплуатации ESB неизбежно возникают следующие расходы.
- Приобретение лицензий для тех компонентов, которые не являются свободно распространяемым программным обеспечением. Так, например, ESB Mule является open-source-продуктом, но отдельные его компоненты (Anypoint ) доступны только в рамках платной годовой подписки.
- Организация IT-инфраструктуры: покупка и амортизация оборудования, аренда серверной стойки в дата-центре или приобретение серверов, IaaS, SaaS и т. д.
Стоимость владения лицензиями и содержания инфраструктуры на проекте среднего размера составляет 100–300 тыс. руб. в месяц.
Оптимальная команда для внедрения ESB
Если вы планируете внедрять ESB силами собственной команды, вам обязательно потребуются следующие специалисты:
- инженер уровня senior или IT-архитектор, который проведёт аудит IT-систем и интегрируемых приложений, проконтролирует выбор технологического стека и разработает стратегию внедрения шины;
- middle-инженер, который реализует интеграцию (можно привлечь к проекту дополнительных инженеров и вести параллельную работу над несколькими задачами, тем самым ускоряя общий процесс).
Важный нюанс: команда должна быть знакома с low-code-подходом, а ещё лучше — непосредственно с ESB. Опыт создания правильных интеграций через middleware позволит избежать «ошибок новичков» и не допустить удорожания проекта.
Но поскольку у бизнеса нет постоянной необходимости в этих компетенциях, чаще всего в штате компаний отсутствуют инженеры с такой специализацией и опытом внедрения ESB. В таком случае соответствующую работу приходится передавать на аутсорсинг.
Оптимальная команда для эксплуатации ESB
Для регулярной эксплуатации внедрённой шины требуется как минимум один специалист уровня citizen developer, которому поручаются следующие задачи:
- разбор инцидентов и решение возникающих проблем;
- внесение изменений в имеющиеся интеграции;
- создание новых потоков интеграций.
Если ESB качественно задокументирована на этапе внедрения, а системы логирования и мониторинга работают исправно, одного человека для эксплуатации шины будет вполне достаточно.
По нашему опыту, компании обычно привлекают к исполнению подобных задач штатных сотрудников и лишь по сложным вопросам обращаются к IT-интеграторам, которые осуществили внедрение и составили документацию.
Кейсы внедрения ESB из опыта KT.Team
Технологический стек, сроки внедрения и команда, которая будет реализовывать его, зависят от множества деталей, уникальных для каждого случая. Мы приведём в пример два кейса, которые наглядно демонстрируют специфику разных способов внедрения ESB. В рамках этой статьи мы не можем раскрывать подробности ситуаций, в которых оказывались наши клиенты. Приведём лишь общую информацию, которая даёт представление о действительной стоимости внедрения шины.
Кейс первый: российская компания в отрасли тяжёлого машиностроения
Размер компании: более 10 тыс. человек, свыше 10 производств.
Причина внедрения ESB: к группе компаний присоединяются новые производственные предприятия, как следствие — необходимо интегрировать их IT-системы, процессы и данные в IT-инфраструктуру всей группы.
Срок внедрения: два месяца от подписания контракта до запуска MVP.
Фазы внедрения:
- анализ данных и изучение текущей архитектуры (две недели);
- разработка и настройка пилотного проекта (четыре недели);
- передача в эксплуатацию и подготовка масштабирования (две недели).
Задействованные специалисты в штате заказчика: руководитель проекта, методолог данных, IT-команды новых производств и управляющей компании группы.
Задействованные специалисты в штате подрядчика: проектный менеджер, техлид, разработчик ESB-интеграций.
Хостинг: собственные серверы (24-ядерный процессор, 30 Гбайт оперативной памяти, SSD-накопитель ёмкостью 480 Гбайт).
Технологический стек для имплементации ESB:
- коннекторы и визуальная среда разработки интеграций — WSO2;
- брокер сообщений — Apache Kafka;
- логирование и мониторинг — ELK Stack;
- дашборды и уведомления — Grafana.
Платные лицензии: не требуются, все компоненты относятся к категории свободного программного обеспечения.
Стоимость услуг интегратора: 3 млн руб. — пилотный проект.
Кейс второй: производство и продажа китайских товаров в России через собственную e-commerce-платформу, сетевой ретейл и маркетплейсы
Размер компании: более 300 человек.
Объём нагрузки: поддержка ERP для более чем 10 каналов продаж, 50 категорий и 300 подкатегорий товаров.
Причина внедрения ESB: необходимость организации стабильной выгрузки данных на постоянно растущее число каналов продаж (включая партнёрские) с автоматическим учётом их требований к предоставляемой информации.
Срок внедрения: четыре месяца от подписания контракта до запуска проекта.
Фазы внедрения:
- анализ данных и изучение требований каналов продаж (четыре недели);
- проектирование, настройка и проверка интеграций на части данных (две недели);
- масштабирование интеграций на остальные данные (восемь недель);
- передача в эксплуатацию (две недели).
Задействованные специалисты в штате заказчика: руководитель проекта, ERP-программист.
Задействованные специалисты в штате подрядчика: проектный менеджер, техлид, разработчик ESB-интеграций.
Хостинг: предоставлен облачным провайдером.
Технологический стек для имплементации ESB:
- коннекторы и визуальная среда разработки интеграций — WSO2;
- брокер сообщений — RabbitMQ;
- логирование и мониторинг — ELK Stack;
- дашборды и уведомления — Grafana.
Платные лицензии: не требуются, все компоненты относятся к категории свободного программного обеспечения.
Стоимость услуг интегратора: 4,5 млн руб. — пилотный проект.
Стоимость инфраструктуры: 100 тыс. руб. в месяц.
Наиболее распространённые ошибки при внедрении ESB
Первая ошибка — осуществление интеграции приложений без подсистем логирования и мониторинга. В конечном счёте компания, внедрившая такой урезанный ESB-слой, будет узнавать об инцидентах реактивно. Представьте ситуацию: логисты должны отправить заказчику оплаченный товар, но не находят его на складе и сообщают о несоответствии фактических складских остатков данным в WMS.
Вторая часто совершаемая ошибка — реализация в ESB сложных механизмов интеграции. Возьмём в качестве примера онлайн-магазин. Для отправки карточки товара на маркетплейс требуются данные об остатках, цене и позиции, которые хранятся в трёх разных системах. Информация о складских остатках обновляется раз в 15 секунд (около 40 тыс. раз в неделю), о цене — раз в час (168 раз в неделю), о позиции — раз в неделю.
- Если при каждом изменении сведений в карточке товара запрос будет приходить во все три системы, возникнет избыточный обмен данными. В большинстве случаев меняются только остатки, что генерирует еженедельные по 40 тыс. обращений в каждую из трех систем, суммарно — 120 тыс. При этом PIM-система с информацией о товарах обрабатывает в 40 тыс. раз больше запросов, чем действительно необходимо!
- Если же обращаться к каждой системе по отдельности, только при изменении данных внутри неё, получатся приблизительно те же 40 тыс. сообщений в неделю в сумме — в три раза меньше. При такой реализации базам, хранящим сведения о ценах и позициях, уже не обязательно выдерживать неоправданное количество обращений, а шина нагружена втрое меньше.
Даже графическое отображение обеих схем наглядно демонстрирует, насколько первый вариант более запутан, неочевиден и подвержен возникновению ошибок.
Избыточный обмен данными несложно выразить в реальных денежных потерях, оценив стоимость инфраструктуры, поддерживающей дополнительную нагрузку, поэтому при имплементации ESB необходимо учитывать бизнес-логику информационной системы.
Ещё один подводный камень, о который легко споткнуться при внедрении сервисной шины, связан с использованием SaaS с оплатой за запрос, взимающих оплату не за месяц, а за запрос. Нужно рассчитать будущие расходы исходя из предполагаемой нагрузки. С этим поможет выстроенная схема to-be-архитектуры, позволяющая оценить примерное число обращений к каждой из систем и приблизительное количество переданных пакетов информации. Если их оценочная стоимость уже сейчас превышает стоимость виртуальных серверов за ту же единицу времени — очевидно, что выбор следует сделать в пользу последних.
